Guided Demonstration of Oberon/F for Mac OS, Release 1.2.
About this Tour
This text is a quick introduction to Oberon/F. Read it and follow the small hands
on examples to get a feeling for the way how Oberon/F works.
Oberon/F
Oberon/F is a cross-platform component framework. Currently, versions for Windows 3.1/95/NT and Mac OS 7 are available; other versions are planned. Oberon/F source code and data files are completely portable. Oberon/F fully adheres to the underlying platform's user interface; i.e. on a Macintosh it is a genuine Mac application, and on Windows it is a true Windows application. Still, full access to the underlying platform is possible when desired; e.g. access to Windows DLLs, or to Macintosh toolbox calls and code fragments.
Oberon/F is a cross-platform component framework. Oberon/F is designed to simplify creation and integration of software components. A software component may provide a particular kind of service, e.g. a spelling checker, or it may be an editor that can be embedded in a document, e.g. a spreadsheet object. Oberon/F components can be be freely mixed and matched by the end-user, in order to customize his or her working environment. Oberon components can work together with other components, e.g. OLE2 objects or OpenDoc parts (forthcoming).
Oberon/F is a cross-platform component framework. It provides a number of extensible programming interfaces. These interfaces are much simpler and safer, and platform-independent moreover, than basic Windows or Mac OS routines. The framework is extensible. It is always possible to create new components that implement the same interfaces as other existing components, or which even add new interfaces themselves.
Oberon/F is also an integrated development environment for the programming language Oberon. Since the development environment Oberon/F is identical to the production run
time environment Oberon/F, rapid development (RAD) is possible. The language Oberon is component-oriented, i.e. it simplifies the creation and integration of software components. Technically speaking, component-orientation means that a languages supports essential features of object-oriented programming, plus type safety, garbage collection, and dynamic linking.
Being a direct descendant of Pascal and Modula
2, Oberon is easy to learn and to teach and programs are easy to read. Oberon is simple enough to serve as a scripting language, yet powerful enough to enable system
level programming: Oberon/F itself is entirely written in Oberon. The Oberon compiler produces fast, native, 32-bit code.
Now let's have a look at some standard Oberon/F components. Views are the most interesting components; they can be put into documents or other views. Views can be edited and resized in place. This demo text contains several embedded views. Here is a first one: a picture view without editing capabilities; it can be resized by first clicking into the picture and then dragging the displayed resize handles. Resizing constraints are resolved on the fly: in the example, the picture view always stays in proportion.
A picture view as an example of an
embedded document component
The Oberon/F framework supports drag & drop editing. To copy, hold down the option key when starting to drag.
Almost all operations in Oberon/F are subject to a multi
level undo/redo feature. In fact, the framework makes it so easy to program something in an undoable fashion that it is almost more involved not to do so.
Program Development
The following embedded component is a fully editable text, showing the complete source of a small Oberon module. To compile the module, focus the embedded part by clicking into it (e.g. click on the keyword PROCEDURE), and then execute Compile from menu Dev.
ObxHello0 is a minimal "hello world" program in Oberon. It writes a single line to the system log text. Execute Open
Log from menu Info to display the system log, if it is not open already.
Exported items in Oberon modules are marked by a trailing asterisk; there are no separate header files, definition modules, or the like. Consistency of interfaces and implementations is fully checked by the compiler; version integrity is checked by the dynamic linker.
Module ObxHello0 exports a single command Do. Commands are Oberon procedures that can be called by the user; i.e. they can be executed directly from the user interface. There is no need for a central top
level module or a "main" procedure. A command can be added to a menu, attached to a button, or executed directly from within a text. To do the latter, the name of the command must be preceded by the name of the implementing module:
ObxHello0.Do
To execute a command by name, simply select the command string and invoke Execute from menu Dev. Another possibility is to precede the command name with a special embedded component, called a commander
that can be inserted anywhere into a text using Insert
Commander from menu Tools. Clicking on a commander executes the appropriate command.
If the source contains errors detectable by the compiler, these are flagged directly in the text. For example, the following module version erroneously imports the (non
existing) module Out0, instead of Out. Try to compile the module - the compiler inserts special embedded components, error markers, flagging the errors that it found. The compiler also writes a report to the system log.
By clicking on an error marker, it is expanded to display a short error message. Correct the mistake (delete the superfluous 0 in IMPORT Out0), and compile again. The marker disappears, and the module is compiled successfully.
The set of currently loaded modules can be inspected using Loaded
Modules from menu Info. The interfaces of modules (loaded or not) can be displayed using the browser: select a module name and execute Interface from menu Info.
A module remains loaded until it is explicitly unloaded, or until Oberon/F is restarted. To unload a module, select the module name and execute Unload
Module
List from menu Dev. For example, unload ObxHello0, modify the string "Hello world", recompile ObxHello0, and activate ObxHello0.Do again. Note that your changes do not affect the running system until after you have unloaded the old module. Such an explicit unloading is a very useful mechanism to allow major changes in multiple modules, while still using and working with the previous version.
Linking Programs to Forms
Besides the text and programming subsystems, the standard Oberon/F configuration also comes with a form subsystem, including a visual designer. Forms are e.g. data entry masks or dialog boxes.
The following module defines a simple record variable to be used for a data entry form.
After compiling the module, a dialog box can be created for the variable ObxAdr.adr using command New
Form... from menu Dev. Just enter the name of the exported global variable ObxAdr.adr into the link field, and click on the Create button. The type information extracted by the compiler is available to Oberon/F at run-time, which is used to automatically create a data-entry window for the form, with a simple default layout.
The created layout can be edited, and then opened as a dialog using the Open as Aux Dialog command in menu Dev.
The text entry fields and the checkbox are directly linked to the fields name, email, and getsUpdates of the variable ObxAdr.adr. The button is linked to the field Text, a procedure variable initialized to refer to procedure Text in module ObxAdr. Clicking the button causes procedure Text to be called. In turn, a new text is created, a report based on the variable adr is written to the text, a new text view is created, and used to open a window displaying the report. Next, the dialog variable is cleared and the system is notified that the variable has changed, causing the form's display to resynchronize with the changed variable.
Text entry fields, checkboxes, and other so-called controls have properties that can be inspected and modified by a suitable control property inspector. Instead of first writing a module and then creating an initial layout, the form can be constructed first, and the corresponding module written later. An Oberon/F dialog box does not necessarily correspond to exactly one record variable. The individual controls of a dialog box may be linked to records in different modules, and a dialog box may also contain other views which are not controls, e.g. pictures.
A form can be saved from within the visual editor; thereafter it can be attached to a menu entry, or another dialog's button. Dialogs are saved in the standard document format, and in a platform
independent way.
And more ...
After this first impression, you may want to consult your documentation for an in-depth coverage of Oberon/F. Select the Oberon/F
Help item in the Help menu (the icon with the question mark) for an overview over the documentation. From there, the complete on-line documentation can be reached via hyperlinks.